home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000104_owner-urn-ietf _Thu Nov 7 13:29:26 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA01085 for urn-ietf-out; Thu, 7 Nov 1996 13:29:26 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA01077 for <urn-ietf@services.bunyip.com>; Thu, 7 Nov 1996 13:29:23 -0500
  3. Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA23814  (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 13:29:21 -0500
  5. Message-Id: <9611071829.AA23814@mocha.bunyip.com>
  6. Received: by privateer.windrose.omaha.ne.us; Thu Nov  7 12:27 CST 1996
  7. From: "Ryan Moats" <jayhawk@ds.internic.net>
  8. To: "Daniel LaLiberte" <liberte@ncsa.uiuc.edu>,
  9.         "Harald.T.Alvestrand@uninett.no" <Harald.T.Alvestrand@uninett.no>,
  10.         "Peter Deutsch" <peterd@bunyip.com>
  11. Cc: "Karen R. Sollins" <sollins@LCS.MIT.EDU>,
  12.         "Leslie Daigle" <leslie@bunyip.com>,
  13.         "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  14. Date: Thu, 07 Nov 96 12:29:08 
  15. Priority: Normal
  16. X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE
  17. Mime-Version: 1.0
  18. Content-Type: text/plain; charset="us-ascii"
  19. Content-Transfer-Encoding: 7bit
  20. Subject: Re: [URN] some comments
  21. Sender: owner-urn-ietf@services.bunyip.com
  22. Precedence: bulk
  23. Reply-To: "Ryan Moats" <jayhawk@ds.internic.net>
  24. Errors-To: owner-urn-ietf@bunyip.com
  25.  
  26. On Thu, 7 Nov 1996 11:50:05 -0500, Peter Deutsch wrote:
  27.  
  28. >I think I understand the thrust of your argument, and if
  29. >not for the past four or five years of history, I'd agree
  30. >wholeheartedly that we need to remain open to change.
  31. >
  32. >Unfortunately, as someone who has been monitoring and
  33. >(before I was called away by my accountants) participating
  34. >in this debate pretty much since its inception, I'd have
  35. >to echo Karen's concerns.
  36. >
  37. >You are right - if bits or pieces turn out to be broken in
  38. >RFC 1737, then they should to be fixed. That's simply good
  39. >engineering. The problem I see, and I suspect that Karen
  40. >was attempting to address, is that there exist the danger
  41. >that in leaving open the possibility of modifying RFC
  42. >1737, at least some people will take it a mandate to fix
  43. >not just broken specifics, but the conceptual model
  44. >itself. This has been happening since the beginning of
  45. >this work and it's getting old.
  46.  
  47. I fully agree with this.  It was not my intent to break the whole
  48. structure, just fiddle with bits of it if necssary as we move forward.
  49.  
  50. Ryan
  51.